Skip to content

fix(security/UNKNOWN/collector): Update module github.com/opencontainers/runc to v1.3.6 [SECURITY] - #6578

Open
renovate-sh-app[bot] wants to merge 1 commit into
mainfrom
renovate/security-collector-github.comopencontainersrunc
Open

fix(security/UNKNOWN/collector): Update module github.com/opencontainers/runc to v1.3.6 [SECURITY]#6578
renovate-sh-app[bot] wants to merge 1 commit into
mainfrom
renovate/security-collector-github.comopencontainersrunc

Conversation

@renovate-sh-app

@renovate-sh-app renovate-sh-app Bot commented Jun 23, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Change Age Confidence
github.com/opencontainers/runc v1.2.8 → v1.3.6 age confidence

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

runc: Malicious image with /dev symlink can trigger limited host filesystem integrity violations

CVE-2026-41579 / GHSA-xjvp-4fhw-gc47 / GO-2026-5761

More information

Details

Impact

When setting up the container rootfs, setupPtmx and setupDevSymlinks call os.Remove and os.Symlink with a filepath.Join string which allow an image with /dev as a symlink to trick runc into deleting files called ptmx on the host or creating a hardcoded set of symlinks with specific names and targets in an arbitrary pre-existing host directory.

Please note that this issue is not exploitable under Docker because it creates a top-level ro layer that masks any malicious /dev symlink present in the container image (this is also done without mounting the lower layers so there is no opportunity for the malicious /dev symlink to trick it into resolving to some other path). Unfortunately, Podman and containerd† do not do this and so users using those higher-level runtimes with runc can be exploited via a malicious image.

This issue mirrors a somewhat similar issue in crun, which was also published recently.

† Actually, at the time the issue was analysed, containerd had dead code that implemented this feature but the implementation contained several security issues that would arguably have made it more exploitable than in runc. Luckily, the code appears to have never been used (at least since 2017) and the code has since been removed.
Mitigating Factors

There are a few mitigating factors about this issue which reduce the impact for most users quite significantly, and is the reason why we decided to release the fix publicly without an embargo.

While the deletion of ptmx seems like a significant issue, in practice it is quite limited. Notably, devpts does not permit you to unlink /dev/pts/ptmx regardless of privileges and so it is not a usable target for this attack. Additionally, while /dev/ptmx can be unlinked‡, trying to use an image with a symlink from /dev to /dev will cause runc will return an error before it reaches the buggy code (it correctly detects a symlink loop while setting up the mount target and the code correctly scopes the lookup inside the container). Thus, the only files called ptmx that are guaranteed to exist on the system cannot actually be removed by this bug and so only some user file that happens to have that specific name could be deleted, which seems fairly unlikely to happen on real systems.

As for the issue of symlinks, again the impact is likely quite limited. While the creation of arbitrary symlinks could be used to create drop-in files for system services (and thus lead to a container breakout), the hardcoded set of symlink names and targets that this bug allows you to create on the host make it quite unlikely that you would be able to do much more than pollute the host system with dummy symlinks. Here is the complete list of symlinks that can be created with this attack:

  • core → /proc/kcore
  • fd → /proc/self/fd/
  • ptmx → pts/ptmx
  • stdin → /proc/self/fd/0
  • stdout → /proc/self/fd/1
  • stderr → /proc/self/fd/2

Note that none of these symlinks are likely to point to user-controlled data -- the /proc/self/fd/$n symlinks are all properties of the process accessing them (so privileged processes will only see the state they were spawned with) and the pts/ptmx symlink is almost certainly in the same privilege scope as the directory the symlink itself is in. It seems the only somewhat plausible impact would be that a service could return an error when trying to parse one of these symlinks and thus treat it as an invalid configuration file. How arbitrary processes deal with this situation is a bit hard to analyse, but most daemons require configuration files to have certain suffixes (such as .conf) so it's not really clear how large the impact is in practice and it seems there are a few barriers to clear to use this to cause a DoS or other problems.

‡ This would actually be quite problematic if it could occur because glibc seemingly only attempts to use /dev/ptmx when creating new terminals and thus most terminal managers (including tmux) and shell tools (including sudo -- but not su) would fail to start and thus bring the system to a halt. setupPtmx does add a symlink to /dev/pts/ptmx afterwards but on some systems the mode of the host /dev/pts/ptmx is set to 0o000 which would still cause the same DoS issue.
Patches

This issue has been patched in runc 1.3.6, runc 1.4.3, and runc 1.5.0-rc.3.

Workarounds

Using user namespaces restricts this attack fairly significantly such that the attacker can only create/delete inodes in directories that the remapped root user/group has write access to. Unless the root user is remapped to an actual user on the host (such as with rootless containers that don't use /etc/sub[ug]id), this in practice means that an attacker would only be able to create or delete inodes in world-writable directories.

LSMs can restrict the scope of where in the host filesystem runc can be tricked into operating on, though how much this helps is questionable. The default container_runtime_t SELinux label rules (or custom AppArmor rules for the host runc context) may restrict the scope where these filesystem operations can operate on, but we have not done an in-depth analysis on the impact of those kinds of LSM protections.

Resources
Credits

runc thanks "Davias" for initially finding and reporting this issue. The same underlying issue (with varying levels of completeness) was later reported by Arthur Chan (@​arthurscchan from Ada Logics), Junyi Liu (@​mosskappa), and Derek Manzella (@​Dmanzella).

Severity

  • CVSS Score: 4.8 / 10 (Medium)
  • Vector String: CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Malicious image with /dev symlink can trigger limited host filesystem integrity violations in github.com/opencontainers/runc

CVE-2026-41579 / GHSA-xjvp-4fhw-gc47 / GO-2026-5761

More information

Details

Malicious image with /dev symlink can trigger limited host filesystem integrity violations in github.com/opencontainers/runc

Severity

Unknown

References

This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).

Release Notes

opencontainers/runc (github.com/opencontainers/runc)

v1.3.6: runc 1.3.6 -- "On no account should you allow a Vogon to read poetry at you."

Compare Source

This is the sixth patch release of the 1.3.z series of runc. Among some
performance improvements and bugfixes, it includes a fix for a
low-severity vulnerability (CVE-2026-41579) and users are encouraged to
update. As it was a low-severity vulnerability and it was reported by
multiple people, we decided to release it publicly with NO EMBARGO.

Security

This release includes a fix for the following low-severity security issue:

  • CVE-2026-41579 allowed a malicious image with a /dev symlink to have
    limited write access to the host filesystem in ways that our analysis
    indicates was too limited to be problematic in practice. This bug was very
    similar to those fixed in CVE-2025-31133, CVE-2025-52565,
    CVE-2025-31133 and was simply missed at the time when we hardened the
    rootfs preparation code. We have conducted a deeper audit and not found any
    other problematic cases.

    This patchset required backports for #​5190 and #​5285, which were primarily
    code reorganisations that were already backported to runc 1.4 and 1.5.

Fixed
Changed
  • When masking directories with maskPaths, runc will now re-use a single
    tmpfs instance (which is not writable) to reduce the number tmpfs
    superblocks that need to be reaped when containers die (in particular,
    Kubernetes applies masks to per-CPU sysfs directories which get expensive
    quickly). (#​5275, #​5281)
Static Linking Notices

The runc binary distributed with this release are statically linked with
the following GNU LGPL-2.1 licensed libraries, with runc acting
as a "work that uses the Library":

The versions of these libraries were not modified from their upstream versions,
but in order to comply with the LGPL-2.1 (§6(a)), we have attached the
complete source code for those libraries which (when combined with the attached
runc source code) may be used to exercise your rights under the LGPL-2.1.

However we strongly suggest that you make use of your distribution's packages
or download them from the authoritative upstream sources, especially since
these libraries are related to the security of your containers.

Thanks to the following contributors for making this release possible:

Signed-off-by: Aleksa Sarai cyphar@cyphar.com

v1.3.5: runc v1.3.5 -- "Lo viejo funciona!"

Compare Source

This is the fifth patch release of the 1.3.z release series of runc,
and primarily contains a few fixes for issues found in 1.3.4.

Fixed
Changed
Static Linking Notices

The runc binary distributed with this release are statically linked with
the following GNU LGPL-2.1 licensed libraries, with runc acting
as a "work that uses the Library":

The versions of these libraries were not modified from their upstream versions,
but in order to comply with the LGPL-2.1 (§6(a)), we have attached the
complete source code for those libraries which (when combined with the attached
runc source code) may be used to exercise your rights under the LGPL-2.1.

However we strongly suggest that you make use of your distribution's packages
or download them from the authoritative upstream sources, especially since
these libraries are related to the security of your containers.

Thanks to the following contributors for making this release possible:

v1.3.4: runc v1.3.4 -- "Take me to your heart, take me to your soul."

Compare Source

This is the fourth patch release of the 1.3.z release series of runc,
and primarily contains a few fixes for some regressions introduced in
1.3.3.

Fixed
  • libct: fix mips compilation. (#​4962, #​4966)
  • When configuring a tmpfs mount, only set the mode= argument if the
    target path already existed. This fixes a regression introduced in our
    CVE-2025-52881 mitigation patches. (#​4971, #​4976)
  • Fix various file descriptor leaks and add additional tests to detect them as
    comprehensively as possible. (#​5007, #​5021, #​5034)
Changed
  • Downgrade github.com/cyphar/filepath-securejoin dependency to v0.5.2,
    which should make it easier for some downstreams to import runc without
    pulling in too many extra packages. (#​5028)
Static Linking Notices

The runc binary distributed with this release are statically linked with
the following GNU LGPL-2.1 licensed libraries, with runc acting
as a "work that uses the Library":

The versions of these libraries were not modified from their upstream versions,
but in order to comply with the LGPL-2.1 (§6(a)), we have attached the
complete source code for those libraries which (when combined with the attached
runc source code) may be used to exercise your rights under the LGPL-2.1.

However we strongly suggest that you make use of your distribution's packages
or download them from the authoritative upstream sources, especially since
these libraries are related to the security of your containers.

Thanks to the following contributors for making this release possible:

Signed-off-by: Aleksa Sarai cyphar@cyphar.com

v1.3.3: runc v1.3.3 -- "奴らに支配されていた恐怖を"

Compare Source

[!NOTE]
Some vendors were given a pre-release version of this release.
This public release includes two extra patches to fix regressions
discovered very late during the embargo period and were thus not
included in the pre-release versions. Please update to this version.

This release contains fixes for three high-severity security
vulnerabilities in runc (CVE-2025-31133, CVE-2025-52565, and
CVE-2025-52881). All three vulnerabilities ultimately allow (through
different methods) for full container breakouts by bypassing runc's
restrictions for writing to arbitrary /proc files.

Security

  • CVE-2025-31133 exploits an issue with how masked paths are implemented in
    runc. When masking files, runc will bind-mount the container's /dev/null
    inode on top of the file. However, if an attacker can replace /dev/null
    with a symlink to some other procfs file, runc will instead bind-mount the
    symlink target read-write. This issue affected all known runc versions.

  • CVE-2025-52565 is very similar in concept and application to
    CVE-2025-31133, except that it exploits a flaw in /dev/console
    bind-mounts. When creating the /dev/console bind-mount (to /dev/pts/$n),
    if an attacker replaces /dev/pts/$n with a symlink then runc will
    bind-mount the symlink target over /dev/console. This issue affected all
    versions of runc >= 1.0.0-rc3.

  • CVE-2025-52881 is a more sophisticated variant of CVE-2019-19921,
    which was a flaw that allowed an attacker to trick runc into writing the LSM
    process labels for a container process into a dummy tmpfs file and thus not
    apply the correct LSM labels to the container process. The mitigation we
    applied for CVE-2019-19921 was fairly limited and effectively only caused
    runc to verify that when we write LSM labels that those labels are actual
    procfs files. This issue affects all known runc versions.

Added
Static Linking Notices

The runc binary distributed with this release are statically linked with
the following GNU LGPL-2.1 licensed libraries, with runc acting
as a "work that uses the Library":

The versions of these libraries were not modified from their upstream versions,
but in order to comply with the LGPL-2.1 (§6(a)), we have attached the
complete source code for those libraries which (when combined with the attached
runc source code) may be used to exercise your rights under the LGPL-2.1.

However we strongly suggest that you make use of your distribution's packages
or download them from the authoritative upstream sources, especially since
these libraries are related to the security of your containers.

Thanks to the following contributors for making this release possible:

Signed-off-by: Aleksa Sarai cyphar@cyphar.com

v1.3.2: runc v1.3.2 -- "Ночь, улица, фонарь, аптека..."

Compare Source

This is the second patch release of the 1.3.z release series of runc.
It primarily includes some minor fixes for issues found in 1.3.1.

Changed:

  • The conversion from cgroup v1 CPU shares to cgroup v2 CPU weight is
    improved to better fit default v1 and v2 values. (#​4772, #​4785, #​4897)
  • Dependency github.com/opencontainers/cgroups updated from v0.0.1 to
    v0.0.4. (#​4897)

Fixed:

  • runc state: fix occasional "cgroup.freeze: no such device" error.
    (#​4798, #​4808, #​4897)
  • Fixed integration test failure on ppc64, caused by 64K page size so the
    kernel was rounding memory limit to 64K. (#​4841, #​4895, #​4893)
Static Linking Notices

The runc binary distributed with this release are statically linked with
the following GNU LGPL-2.1 licensed libraries, with runc acting
as a "work that uses the Library":

The versions of these libraries were not modified from their upstream versions,
but in order to comply with the LGPL-2.1 (§6(a)), we have attached the
complete source code for those libraries which (when combined with the attached
runc source code) may be used to exercise your rights under the LGPL-2.1.

However we strongly suggest that you make use of your distribution's packages
or download them from the authoritative upstream sources, especially since
these libraries are related to the security of your containers.

Thanks to the following contributors who made this release possible:

Signed-off-by: Kir Kolyshkin kolyshkin@gmail.com

v1.3.1: runc v1.3.1 -- "この瓦礫の山でよぉ"

Compare Source

This is the first patch release of the 1.3.z release series of runc. It
primarily includes some minor fixes for issues found in 1.3.0.

Fixed
  • Container processes will no longer inherit the CPU affinity of runc by
    default. Instead, the default CPU affinity of container processes will be
    the largest set of CPUs permitted by the container's cpuset cgroup and any
    other system restrictions (such as isolated CPUs). (#​4041, #​4815, #​4858)
  • Setting linux.rootfsPropagation to shared or unbindable now functions
    properly. (#​1755, #​1815, #​4724, #​4789)
  • Close seccomp agent connection to prevent resource leaks. (#​4796, #​4799)
  • runc delete and runc stop can now correctly handle cases where
    runc create was killed during setup. Previously it was possible for the
    container to be in such a state that neither runc stop nor runc delete
    would be unable to kill or delete the container. (#​4534, #​4645, #​4757,
    #​4788)
  • runc update will no longer clear intelRdt state information. (#​4828,
    #​4833)
  • CI: Fix exclusion rules and allow us to run jobs manually. (#​4760, #​4763)
Changed
  • Improvements to the deprecation warnings as part of the
    github.com/opencontainers/cgroups split. (#​4784, #​4788)
  • Disable the dmem controller in our cgroup tests, as systemd does not yet
    support it. (#​4806, #​4811)
  • /proc/net/dev is no longer included in the permitted procfs overmount
    list. Its inclusion was almost certainly an error, and because /proc/net
    is a symlink to /proc/self/net, overmounting this was almost certainly
    never useful (and will be blocked by future kernel versions). (#​4817, #​4820)
  • Simplify the prepareCriuRestoreMounts logic for checkpoint-restore.
    (#​4765, #​4871)
  • CI: Bump golangci-lint to v2.1. (#​4747, #​4754)
  • CI: Switch to GitHub-hosted ARM runners. Thanks again to @​alexellis for
    supporting runc's ARM CI up until now. (#​4844, #​4856, #​4867)
Static Linking Notices

The runc binary distributed with this release are statically linked with
the following GNU LGPL-2.1 licensed libraries, with runc acting
as a "work that uses the Library":

The versions of these libraries were not modified from their upstream versions,
but in order to comply with the LGPL-2.1 (§6(a)), we have attached the
complete source code for those libraries which (when combined with the attached
runc source code) may be used to exercise your rights under the LGPL-2.1.

However we strongly suggest that you make use of your distribution's packages
or download them from the authoritative upstream sources, especially since
these libraries are related to the security of your containers.

Thanks to the following contributors who made this release possible:

Signed-off-by: Aleksa Sarai cyphar@cyphar.com

v1.3.0: runc v1.3.0 -- "Mr. President, we must not allow a mine shaft gap!"

Compare Source

This is the first release of the 1.3.z release branch of runc. It
contains a few minor fixes for issues found in 1.3.0-rc.2.

This is the first release of runc that will follow our new release and
support policy (see RELEASES.md for more details). This means that, as
of this release:

  • As of this release, the runc 1.2.z release branch will now only
    receive security and "significant" bugfixes.
  • Users are encouraged to plan migrating to runc 1.3.0 as soon as
    possible.
  • Due to its particular situation, runc 1.1.z is officially no longer
    supported and will no longer receive any updates (not even for
    critical security issues). Users are urged (in the strongest possible
    terms) to upgrade to a supported version of runc.
  • Barring any future changes to our release policy, users should expect
    a runc 1.4.0 release in late October 2025.
Fixed
  • Removed pre-emptive "full access to cgroups" warning when calling
    runc pause or runc unpause as an unprivileged user without
    --systemd-cgroups. Now the warning is only emitted if an actual permission
    error was encountered. (#​4709)
  • Several fixes to our CI, mainly related to AlmaLinux and CRIU. (#​4670,
    #​4728, #​4736)
Changed
  • In runc 1.2, we changed our mount behaviour to correctly handle clearing
    flags. However, the error messages we returned did not provide as much
    information to users about what clearing flags were conflicting with locked
    mount flags. We now provide more diagnostic information if there is an error
    when in the fallback path to handle locked mount flags. (#​4734)
  • Upgrade our CI to use golangci-lint v2.0. (#​4692)
  • runc version information is now filled in using //go:embed rather than
    being set through Makefile. This allows go install or other non-make
    builds to contain the correct version information. Note that
    make EXTRA_VERSION=... still works. (#​418)
  • Remove exclude directives from our go.mod for broken cilium/ebpf
    versions. v0.17.3 resolved the issue we had, and exclude directives are
    incompatible with go install. (#​4748)
Static Linking Notices

The runc binary distributed with this release are statically linked with
the following GNU LGPL-2.1 licensed libraries, with runc acting
as a "work that uses the Library":

The versions of these libraries were not modified from their upstream versions,
but in order to comply with the LGPL-2.1 (§6(a)), we have attached the
complete source code for those libraries which (when combined with the attached
runc source code) may be used to exercise your rights under the LGPL-2.1.

However we strongly suggest that you make use of your distribution's packages
or download them from the authoritative upstream sources, especially since
these libraries are related to the security of your containers.

Thanks to the following contributors for making this release possible:

Signed-off-by: Aleksa Sarai cyphar@cyphar.com

v1.2.9: runc v1.2.9 -- "Stars hide your fires, let me rest tonight."

Compare Source

This is the ninth patch release of the 1.2.z release series of runc, and
primarily contains a few fixes for some regressions introduced in 1.2.8.

Fixed
  • libct: fix mips compilation. (#​4962, #​4965)
  • When configuring a tmpfs mount, only set the mode= argument if the
    target path already existed. This fixes a regression introduced in our
    CVE-2025-52881 mitigation patches. (#​4971, #​4974)
  • Fix various file descriptor leaks and add additional tests to detect them as
    comprehensively as possible. (#​5007, #​5021, #​5027)
Changed
  • Downgrade github.com/cyphar/filepath-securejoin dependency to v0.5.2,
    which should make it easier for some downstreams to import runc without
    pulling in too many extra packages. (#​5027)
Static Linking Notices

The runc binary distributed with this release are statically linked with
the following GNU LGPL-2.1 licensed libraries, with runc acting
as a "work that uses the Library":

The versions of these libraries were not modified from their upstream versions,
but in order to comply with the LGPL-2.1 (§6(a)), we have attached the
complete source code for those libraries which (when combined with the attached
runc source code) may be used to exercise your rights under the LGPL-2.1.

However we strongly suggest that you make use of your distribution's packages
or download them from the authoritative upstream sources, especially since
these libraries are related to the security of your containers.

Thanks to the following contributors for making this release possible:

Signed-off-by: Aleksa Sarai cyphar@cyphar.com

Configuration

📅 Schedule: (UTC)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

  • If you want to rebase/retry this PR, check this box

Need help?

You can ask for more help in the following Slack channel: #proj-renovate-self-hosted. In that channel you can also find ADR and FAQ docs in the Resources section.

@renovate-sh-app
renovate-sh-app Bot requested a review from a team as a code owner June 23, 2026 03:33
@github-actions

github-actions Bot commented Jun 23, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

🔍 Dependency Review

github.com/opencontainers/runc v1.2.8 → v1.3.6 — ⚠️ Needs Review

Summary:

  • This upgrades runc across a minor release line (v1.2 → v1.3). runc’s CLI is stable, but its internal Go API (libcontainer/*, cgroups, configs, etc.) is not guaranteed to be. Most consumers compile cleanly across 1.2 → 1.3, but code that imports runc as a library (especially libcontainer/cgroups and related configs) should be recompiled and lightly exercised.
  • No required code changes are typically needed for common usages like passwd/group parsing via libcontainer/user or reading cgroup stats via the public cgroup managers, but do run a build to surface any API drifts.

What to check in your codebase:

  • If you do not import github.com/opencontainers/runc/... directly (only transitive deps use it), there are no project code changes to make.
  • If you import runc as a library, pay attention to:
    • libcontainer/cgroups manager interfaces (systemd and cgroupfs)
    • libcontainer/configs.Resources and cgroup v2 “Unified” settings
    • libcontainer/seccomp structs and constants
    • Possible expansion of stats structures (additional fields are additive but can affect strict equality checks or marshaling expectations)

Build/toolchain:

  • runc v1.3.x requires a modern Go toolchain (at least Go 1.20+; many builds for runc 1.3 are done with newer Go). Ensure your module builds with a recent Go version.

Actionable checks:

  • Rebuild with the new version to detect any API drifts:
    • go mod tidy && go build ./...

If you hit any compile errors, these are the most common adjustments:

  1. cgroup Resource fields (additive field expansions)
  • If your code assigns configs.Resources wholesale and the upstream added new fields, you typically don’t need to change anything; however, if you rely on a “copy by literal” pattern, prefer keyed fields to remain future-safe.

Example (no behavior change, keyed fields for clarity):

- res := configs.Resources{Devices: []*devices.Rule{rule}, Memory: 1<<30}
+ res := configs.Resources{
+   Devices: []*devices.Rule{rule},
+   Memory:  1<<30,
+   // (Leave any new fields at their zero-value unless you intend to use them.)
+}
  1. cgroups manager initialization (systemd vs cgroupfs)
  • If your code constructs cgroup managers explicitly, keep using the factory as recommended. This remains the most compatible pattern across releases.
- m, err := libcontainercgroups.NewManager("systemd", paths, &res)
+ m, err := libcontainercgroups.NewManager("systemd", paths, &res)
  // No change typically required; keep using the factory API.
  1. Seccomp configuration additions
  • If you populate configs.Seccomp, new fields (if any were added) are optional. Use keyed literals and leave new fields unset to preserve prior behavior.
- sec := &configs.Seccomp{DefaultAction: configs.ActErrno, Syscalls: syscalls}
+ sec := &configs.Seccomp{
+   DefaultAction: configs.ActErrno,
+   Syscalls:      syscalls,
+   // New optional fields can be omitted to retain previous behavior.
+}
  1. If you only use runc’s libcontainer/user for passwd/group parsing
  • No migration is generally needed. If you prefer to decouple from runc internals in the future, a drop-in alternative is github.com/moby/sys/user (not required for this upgrade).

References (for maintainers to verify):

  • Review release notes/changelog for v1.3.0 … v1.3.6 and any 1.2.x patch notes newer than v1.2.8 in the runc repository to confirm no project-specific API you rely on was removed or behaviorally changed.

Conclusion:

  • Likely no code changes are required provided you’re not depending on unstable internals. Rebuild and run basic runtime/cgroup-related paths to confirm.

Notes

  • Only one dependency changed in the provided diff: a replace of runc v1.2.8 → v1.3.6. No net-new dependencies were added in the shown go.mod diff.

@renovate-sh-app
renovate-sh-app Bot force-pushed the renovate/security-collector-github.comopencontainersrunc branch from 22aca58 to 078ea0f Compare June 23, 2026 09:40
@kgeckhart kgeckhart mentioned this pull request Jun 23, 2026
Open
@renovate-sh-app
renovate-sh-app Bot force-pushed the renovate/security-collector-github.comopencontainersrunc branch 3 times, most recently from c9dae71 to 950dc5f Compare June 25, 2026 12:39
@renovate-sh-app renovate-sh-app Bot changed the title fix(security/MEDIUM/collector): Update security collector github.com/opencontainers/runc to v1.3.6 [SECURITY] fix(security/MEDIUM/collector): Update module github.com/opencontainers/runc to v1.3.6 [SECURITY] Jun 29, 2026
@renovate-sh-app
renovate-sh-app Bot force-pushed the renovate/security-collector-github.comopencontainersrunc branch 3 times, most recently from 3725ffe to 59039dc Compare July 3, 2026 15:38
@renovate-sh-app renovate-sh-app Bot changed the title fix(security/MEDIUM/collector): Update module github.com/opencontainers/runc to v1.3.6 [SECURITY] fix(security/UNKNOWN/collector): Update module github.com/opencontainers/runc to v1.3.6 [SECURITY] Jul 8, 2026
@renovate-sh-app renovate-sh-app Bot changed the title fix(security/UNKNOWN/collector): Update module github.com/opencontainers/runc to v1.3.6 [SECURITY] fix(security/UNKNOWN/collector): Update module github.com/opencontainers/runc to v1.3.6 [SECURITY] - autoclosed Jul 9, 2026
@renovate-sh-app renovate-sh-app Bot closed this Jul 9, 2026
@renovate-sh-app
renovate-sh-app Bot deleted the renovate/security-collector-github.comopencontainersrunc branch July 9, 2026 15:25
@renovate-sh-app renovate-sh-app Bot changed the title fix(security/UNKNOWN/collector): Update module github.com/opencontainers/runc to v1.3.6 [SECURITY] - autoclosed fix(security/UNKNOWN/collector): Update module github.com/opencontainers/runc to v1.3.6 [SECURITY] Jul 9, 2026
@renovate-sh-app renovate-sh-app Bot reopened this Jul 9, 2026
@renovate-sh-app
renovate-sh-app Bot force-pushed the renovate/security-collector-github.comopencontainersrunc branch 4 times, most recently from c6ce7e9 to 7a62b66 Compare July 14, 2026 16:30
@renovate-sh-app
renovate-sh-app Bot force-pushed the renovate/security-collector-github.comopencontainersrunc branch 2 times, most recently from be4e4bf to 048b24e Compare July 23, 2026 19:29
@renovate-sh-app
renovate-sh-app Bot force-pushed the renovate/security-collector-github.comopencontainersrunc branch from 048b24e to ea2f4ee Compare July 29, 2026 10:28
@renovate-sh-app
renovate-sh-app Bot force-pushed the renovate/security-collector-github.comopencontainersrunc branch from ea2f4ee to f9f6ebc Compare August 5, 2026 13:25
@renovate-sh-app
fix(security/UNKNOWN/collector): Update module github.com/opencontain…
bf9f20a 
…ers/runc to v1.3.6 [SECURITY]

| datasource | package                        | from   | to     |
| ---------- | ------------------------------ | ------ | ------ |
| go         | github.com/opencontainers/runc | v1.2.8 | v1.3.6 |


Signed-off-by: renovate-sh-app[bot] <219655108+renovate-sh-app[bot]@users.noreply.github.com>
@renovate-sh-app
renovate-sh-app Bot force-pushed the renovate/security-collector-github.comopencontainersrunc branch from f9f6ebc to bf9f20a Compare August 13, 2026 22:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

automerge-security-update severity:UNKNOWN update-minor

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants